e-Business: Shopping Chart

Melanjutkan tulisan saya tentang e-Business, yakni mengenai Storefront Model disini. Maka kali ini saya akan menulis tentang teknologi Shopping Chart.

Seperti telah saya kemukan sebelumnya, model e-bisnis Storefront Model, berusaha untuk mempertemukan secara langsung seller dan buyer, dalam platform Web 2.0. Model bisnis ini menjadi "possible" dilakukan karena ditemukannya teknologi shopping chart. Teknologi shopping chart sebenarnya adalah sebuah teknologi yang memungkinkan calon pembeli memesan produk yang akan dibeli dan kemudian menyimpannya sebelum dibayar. Konsep shopping chart sebenarnya seperti keranjang belanja saat kita berbelanja di hypermart ataupun supermarket. Tentu saja, konsep ini berbeda dengan keranjang belanja saat kita berbelanja di pasar tradisional. Karena di pasar tradisional, keranjang belanja ditujukan untuk menampung barang-barang ÿang telah dibayar", sedangkan keranjang belanja di hypermart atau supermarket, ditujukan untuk menampung barang-barang yang belum dibayar, bahkan belum tentu dibeli. Inilah pemahaman kunci dari teknologi shopping chart.

Jadi, dengan teknologi shopping chart, dibutuhkan dukungan teknologi otentikasi user, user interface catalog, dan tentu saja, teknologi basis data relational. Pihak merchant mau tidak mau harus menyediakan server untuk data storage dan server untuk web applications. DBMS (database management system) harus bisa mengelola proses storing, reporting dan updating data dalam jumlah besar dan secara online. Bisa dibayangkan sekiranya pada saat yang bersamaan website server harus melayani "permintaan"data processing dalam jumlah besar pada saat yang bersamaan. Maka tentu saja, implementasi DBMS harus menjadi salah satu pertimbangan utama, bagi para pebisnis yang ingin melakukan e-bisnis menurut model storefront.

Isu security dan privacy memang masih menghantui teknologi shopping chart. Namun demikian "success story" beberapa pebisnis online pun makin terkenal. Lihat saja Amazon.com. Dibuka di tahun 1994, maka Amazon.com memasuki dunia bisnis online awalnya hanya sebagai retailer mail-order book. Lini produk Amazon.com awalnya hanya buku sekarang telah berkembang menjadi banyak produk seperti CD, DVD, electronic cards, consumer electronics, perangkat keras berbagai jenis dan masih banyak lagi. Perkembangan terakhir dari Amazon.com malah telah "mengubah"model e-bisnisnya dengan mengimplementasikan teknologi Cloud Computing (yang akan saya ulas pada bagian tersendiri).

Proses commerce di Amazon.com dibuat menjadi sangat sederhana. Kita dapat langsung masuk ke halaman depan Amazon.com, kemudian langsung memilih produk yang ingin kita beli. Fitur "SEARCH BOX" yang terletak dibagian atas tengah halaman web, sangat menyolok dan lumayan besar. Disisi kanan halaman utama ditampilkan pilihan belanja menurut departemen, yakni produk- produk yang telah dikategorikan oleh management Amazon.com. Setelah memilih produk yang ingin kita beli, kita tinggal menekan ADD TO SHOPPING CHART yang ada di sebelah kanan atas halaman web. Shopping chart akan memproses data pembelian tersebut, dan kepada kita akan ditampilkan opsi menambah, mengurangi, membatalkan kuantitas setiap item produk yang ingin kita beli, ataupun untuk memilih selesai belanja dan melanjutkan belanja.

Pembeli langganan, dapat memanfaatkan teknologi 1-Click System. Teknologi ini sebenarnya yang saya kagumi dari Amazon.com, karena dapat "mengingat" sejarah belanja saya, sehingga membantu saya untuk lebih efisien dalam "menemukan" produk yang ingin kita beli selanjutnya.

Selain amazon.com, maka kita bisa melihat www.etoys.com, dan www.webvan.com sebagai contoh model bisnis storefront dengan teknologi shopping chart.

e-Business (Bagian 1: Pengantar)

e-Business Models

Pengantar: saya tertarik mulai menulis tentang e-business. Sebagai bekas mahasiswa, saya memang pernah mengikuti kuliah tentang e-Business di Fakultas Ilmu Komputer - Magister Teknologi Informasi. Selain itu, saya juga sering ditugaskan untuk mengampu mata kuliah Aplikasi Sistem Enterprise dan e-Business. Pengalaman sebagai seorang praktisi e-Business juga akan turut mewarnai tulisan-tulisan saya ini. Semoga bermanfaat.

Pengertian Dasar

Banyak yang telah mencoba mengartikan e-business. Tapi, secara sederhana kita dapat memahami e-business sebagai ä company that has an online presence. Entitas bisnis yang hadir secara online, dan dapat melakukan aktivitas selling (menjual), trade (berdagang), barter (bertukar-jasa) atau melakukan transaksi disebut sebagai e-commerce. Tentu saja pengertian ini dapat diperdebatkan, tapi saya melihatnya dari sudut pandang seorang praktisi.

Bahasan saya tentang e-Business, saya awali dengan Model e-Business. e-Business Model sebenarnya merupakan kombinasi dari policy, operasionalisasi, teknologi dan ideologi yang dianut oleh entitas bisnis online. Jadi, secara singkat dapat dikatakan bahwa e-Business tidak hanya "melulu" tentang teknologi (dalam hal ini teknologi Web 2.0), tapi juga berhubungan dengan proses yang ada, dan terutama budaya organisasi itu sendiri.

Secara teori, maka model e-business dibedakan menjadi:

1). Storefront Model; dimana teknologi yang digunakan dibedakan menjadi Shopping-cart Technology dan Online Shopping Malls

2). Auction Model

3). Portal Model

4). Dynamic Pricing Models

Storefront model merupakan tipe e-business yang paling populer di kalangan penggiat dunia maya. Bahkan jika masyarakat awam "bercerita" tentang pengalaman melakukan bisnis secara online, maka sebenarnya, mereka "berbisnis"secara "storefront". Model storefront mengkombinasikan transaction processing, security, online payment, dan information storage, sehingga memungkinkan penyedia menampilkan dan menjual produknya pada platform Web 2.0. Model storefront sebenarnya adalah bentuk dasar e-commerce. Storefront mempertemukan buyer dan seller secara langsung.

Teknis proses bisnisnya adalah seperti ini:

1) Untuk melakukan storefront maka diperlukan katalog online, dimana setiap produk yang akan dijual diorganisasikan pada katalog online tersebut.

2) order pemesanan dilakukan menurut official website

3) proses pembayaran pesanan dilakukan pada lingkungan yang secure (dan konfirmasi)

4) proses pengiriman barang yang dipesan kepada pelanggan (dan konfirmasi)

5) proses mengelola data pelanggan

Tren yang berkembang sekarang ini adalah proses yang ke-6, yakni "menghadirkan"official website penjual kepada pembeli. Jadi, dalam platform Web 2.0, pembeli "tidak diharuskan" untuk mendatangi toko, melainkan informasi tentang barang yang dijual yang harus mendatangi calon pembeli.

Beberapa contoh mengenai storefront model adalah More.com dan Ticketmaster.com. More.com adalah sebuah "toko online" yang memfokuskan diri pada produk-produk kesehatan dan kecantikan. Sedangkan Ticketmaster.com menjual ticket untuk konser, olahraga, seni, dll. Kedua toko online ini benar-benar melakukan bisnis online dengan model storefront.

Freemium

Pengantar:

Sebelum membaca bagian ini, para pembaca diharapkan telah membaca tulisan yang dirujuk pada link berikut ini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free?currentPage=all

Saya kira, tidak ada sebuah business model yang benar-benar baru, selain yang dilahirkan oleh abad Web 2.0. Tentu saja kita harus memahami apa yang dimaksud dengan Web 2.0 tersebut. Silahkan untuk membaca tulisan saya tentang Paradigma Web 2.0 disini. Atau untuk tentang Perspektif Teknologi Informasi. Pemahaman pembaca tentang Web 2.0 serta akibat-akibat yang ditimbulkan dari digunakannya teknologi Web 2.0 tersebut sangat penting untuk dipahami.

Chris Anderson (canderson@wired.com) yang merupakan editor in chief of  Wired Magazine; memaparkan mengenai Taxonomy of FREE sebagai berikut:

 1) Freemium

What's free: Web software and services, some content. 

Free to whom: users of the basic version.

This term, coined by venture capitalist Fred Wilson, is the basis of the subscription model of media and is one of the most common Web business models. It can take a range of forms: varying tiers of content, from free to expensive, or a premium "pro" version of some site or software with more features than the free version (think Flickr and the $25-a-year Flickr Pro).

2) Advertising
What's free: content, services, software, and more. 

Free to whom: everyone.

Layanan "menampilkan" iklan yang dilakukan mesin google, adalah sebuah contoh nyata bahwa dalam dunia Web 2.0, advertising sudah menjadi FREE. Lihatlah yang dilakukan oleh Amazon.com, dengan menampilkan fitur "buku yang disarankan".

3)  Cross-subsidies
What's free: any product that entices you to pay for something else. 

Free to whom: everyone willing to pay eventually, one way or another.

4) Zero marginal cost
What's free: things that can be distributed without an appreciable cost to anyone. 

Free to whom: everyone.
5) Labor exchange
What's free: Web sites and services. 

Free to whom: all users, since the act of using these sites and services actually creates something of value.
6) Gift economy
What's free: the whole enchilada, be it open source software or user-generated content. 

Free to whom: everyone.

Untuk studi kasus yang dirujuk Chris Anderson; beliau merujuk pada link-link dibawah ini:

Tentang Webmail bisa dilihat disini: 

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_webmail

Tentang  Air Travel bisa dilihat disini: 

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_air

Tentang CD dan DVD bisa dilihat disini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_prince

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_dvr

Tentang Direktori Help bisa dilihat disini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_411

Saya memilih dua buah studi kasus untuk bahasan kita tentang FREEMIUM:

1) tentang Toko Online Manadokota http://www.manadokota.com/index.php

2) tentang Komunitas Blogger Sulawesi Utara http://www.kawanuablogger.com/

Setiap mahasiswa dipersilahkan untuk mempelajari studi kasus yang dipaparkan oleh Chris A derson tersebut diatas, dan memberi komentar dibagian bawah tulisan ini.

Sedangkan untuk kedua studi kasus yang saya pilihkan, silahkan memberi tanggapan di twitter dengan menggunakan hashtag #MITI dan mencantumkan nama akun @stanlysk, @manadokota dan @bloggermanado.

Selengkapnya bisa ditanyakan saat pertemuan tatap muka.
 

Fase Design

Pada phase disain tim pengembang perangkat lunak melakukan aktivitas untuk menjawab pertanyaan "how to build the system". Tim pengembang akan membuat "system requirements". System requirements menjelaskan aspek-aspek teknik untuk membangun perangkat lunak. Sudah tentu, system requirements ini sangat erat kaitannya dengan functional requirements dan user requirements (yang telah dimodelkan sebelumnya pada fase modelling). Selain melakukan aktivitas yang berhubungan dengan system requirements, maka tim pengembang juga menghasilkan apa yang disebut system specification. Yakni berupa artifak yang terkait dengan pembangunan aplikasi/sistem informasi. 

Beberapa aktivitas umum yang dilakukan di fase disain diantaranya adalah:

1) Menentukan alternatif pilihan apakah akan membuat sendiri, membeli aplikasi jadi atau di-outsource

2) Menerjemahkan model logical (yang telah dibuat pada fase modelling) menjadi physical models.

3) Mendisain "the architecture" dari sistem aplikasi 

4) Menentukan lingkunga implementasi hardware dan software

5) Mendisain sistem masukan dan keluaran, yakni antar-muka penggunanya.

6) Mendisain basis data

7) Mendisain struktur program

8) Membuat laporan dokumentasi (misalnya dokumen SRS)

Saat fase disain berlangsung, biasanya ada beberapa "masalah" yang harus diwaspadai oleh Tim Pengembang, diantaranya adalah ...

1) Feature Creep
ini adalah masalah yang sering terjadi, yakni bertambahnya fitur yang menjadi requirement fungsional dari aplikasi.

2) Silver bullet syndrome
Penjelasan mengenai hal ini sudah saya kupas tuntas disini.

Pengalaman saya dalam mengembangkan aplikasi dan sistem informasi selama ini, menunjukkan bahwa feature creep dan silver bullet syndrome adalah "masalah" yang SELALU terjadi saat fase disain berlangsung. Hal ini tentu saja, harus menjadi perhatian serius dari Tim Pengembang.

Beberapa catatan saya yang terkait pembahasan kuliah Pengantar Fase Disain dapat diklik disini:
1) Tentang Silver Bullet Syndrome
2) Tentang Mengerjakan Proyek Perangkat Lunak
3) Tentang e-Journal Universitas Sam Ratulangi

Catatan:

Slide Kuliah tentang Pengantar Fase Design dapat diunduh disini. 
Pertanyaan dapat diposting sebagai komentar dibawah tulisan ini.

Business Use-case Model

Menggambar Business Use-case Model
 

Business Use-case Model merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Model ini diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat (kadang bersifat optional, dimana dapat diilustrasikan dalam satu atau beberapa business use-case diagram).

Dalam prakteknya Business Use-case Model digunakan bersamaan dengan UML Activity Diagram untuk menggambarkan proses bisnis. Menggunakan model Business Use-case sebenarnya dapat mempertajam pemahaman tim pengembang dan user terkait model bisnis sistem informasi yang akan dikembangkan.
 

Business use-case model dibangun dengan elemen-elemen: Business Actor, Business Use-case, dan Activity Diagram untuk menjelaskan model business use-case
 

Business Actor:
Business actor (aktor bisnis) mengambarkan peran yang dimainkan oleh seorang atau sesuatu yang berinteraksi dengan bisnis. Sebuah business actor mengambarkan seorang customer , partner bisnis, atau sebuah sistem informasi yang berhubungan dengan bisnis kita

Gambar dari Business Actor

 

Business Use-case
Business use-case merupakan urutan tindakan yang dimainkan suatu bisnis yang menghasilkan sebuah nilai yang dapat dilihat dan ditunjukan untuk suatu business actor tertentu. Satu business use-case mewakili satu proses bisnis

Gambar dari Business Use-case

Berikut adalah sebuh Contoh Gambar Business use-case Model dari studi kasus sebelumnya disini

UML Use-case Diagram

Menggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
Sebuah Use-case dapat meng-include fungsionalitas Use-case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa Use-case yang di-include akan dipanggil setiap kali Use-case yang meng-include dieksekusi secara normal. Sebuah Use-case dapat di-include oleh lebih dari satu Use-case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Contoh Use-case (include)

 

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
Sebuah Use-case juga dapat meng-extend Use-case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar Use-case menunjukkan bahwa Use-case yang satu merupakan spesialisasi dari yang lain.

Contoh Use-case (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

Sebuah Video Tutorial tentang UML Use Case Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=Zk-580BqSNY&feature=relmfu

UML Activity Diagram

Langkah pertama yang HARUS dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak.

Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. Pada bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis. Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun. Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak.

Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun.

Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram. 

Pada bagian tulisan ini, saya akan menuliskan tentang memodelkan proses bisnis dengan Activity Diagram. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang: awal proses, decision, akhir proses, proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu

Notasi dalam Activity Diagram

Cara menggambarkan activity diagram:

1. Menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. 

2. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

3. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

4. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya.

Tentang Activity Diagram:

Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan. Activity diagram di bawah ini memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.

Contoh pada Studi Kasus:

Pada sebuah Foodcourt. Pembeli datang ke foodcourt, menuju stand penjual makanan yang dinginkan. Pembeli memesan makanan, jika makanan tersebut ada, maka pesanan disiapkan, jika makanan tersebut tidak ada maka pembeli tidak jadi memesan makanan. Setelah memesan, petugas stand menyiapkan bon dua rangkap dan memberikan bon tersebut kepada pembeli.

Pembeli kemudian membayar makanan yang dibeli di kasir stand dengan menyerahkan bon pembelian. Kasir menghitung jumlah yang harus dibayar pembeli dan menginformasikannya ke pembeli. Pembeli menyiapkan uang dan memberikan kepada kasir. Jika ada kembalian, kasir menghitung kembalian tersebut dan memberikan kembalian beserta bukti pembayaran (struk) serta bon yang sudah ditandai lunas.

Pembeli mencari tempat duduk, penjual stand makanan memberikan makanan kepada pembeli dengan mengambil bon yang sudah ditandai lunas tersebut.

Activity Diagram Pembayaran

Activity Diagram Pemesanan

Sebuah Video Tutorial tentang Activity Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=yAihwmczqsk&feature=related

UML dan Pemodelan Software

Pemodelan pada dasarnya merupakan kegiatan untuk menyederhanakan. Seperti misalnya kita ingin memahami tentang bentuk bumi yang seperti bola. Alih-alih kita melihat bumi dari luar angkasa, maka kita mengambil benda yang “menyerupai” bola, dan kemudian mulai memodelkan bumi yang sebenarnya.

Kegiatan pemodelan perangkat lunak berorientasi obyek adalah kegiatan untuk mencoba menyederhanakan perangkat lunak yang akan kita kembangkan dengan terlebih dahulu membuat model visualisasi (penggambaran model) perangkat lunak yang akan dikembangkan. Pembuatan model visualisasi perangkat lunak dilakukan dengan menggunakan kakas yang disebut Unified Modelling Language atau disingkat UML. 

Jadi, sebenarnya UML adalah:

1. sebuah "bahasa" pemodelan perangkat lunak standar yang dapat digunakan untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-komponen perangkat lunak.
2. bahasa pemodelan visual yang notasi grafis yang ekspresif dalam arti lengkap dan mudah dipahami, baik oleh pengembang maupun user.
3. menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi obyek seperti C++, Java, C# atau VB.NET.

Tiga hal yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:

1. Memahami maksud dan tujuan digunakannya UML
2. Memahami apa yang akan dimodelkan dalam UML
3. Menguasai langkah-langkah pembuatan diagram UML

Ada beberapa notasi grafis dalam UML yang dapat digunakan untuk memodelkan aplikasi perangkat lunak berorientasi obyek. Notasi grafis atau disebut juga diagram tersebut memiliki bermacam-macam sudut-pandang (atau disebut perspektif) untuk menunjukkan model perangkat lunak. Diagram-diagram tersebut juga menunjukkan tingkat abstraksi pemodelan berorientasi obyek yang berbeda-beda. Berikut adalah Ringkasan Diagram UML ver 2.0 yang diambil dari buku System Analysis and Design with UML version 2; An Object-Oriented Approach,2nd Ed. By Allan Dennis, Barbara Wixon, David Tegarden. © John Wiley&Sons, 2010

Bagaimana memodelkan perangkat lunak dengan UML?

Terdapat banyak variasi dalam memodelkan perangkat lunak dengan menggunakan UML. Dibawah ini saya memberikan saran untuk memodelkan perangkat lunak dengan menggunakan UML. Tidak berarti bahwa saran saya ini adalah yang paling tepat, penyesuaian terhadap langkah-langkah pemodelan itu sangat terbuka. Masing-masing pengembang dapat menemukan "best practices"-nya sendiri. Urutan langkah yang disarankan untuk memodelkan perangkat lunak dengan menggunakan UML adalah:

1. Buatlah daftar proses business dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. Langkah ini dapat dilakukan dengan membuat FDD (functional decomposition diagram) ataupun dengan membuat Business Use Case Model dan Business Object Model (BOM).
2. Petakan use case untuk tiap proses business untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem dengan mengisi use case table.
4. Berdasarkan use case table, highlight semua potensial obyek dan dari situ pilihlah obyek yang dapat dijadikan sebuah kelas. Kemudian, gambarkan high-level class digram dan detailed class diagram.
5. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Oleh karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
6. Berdasarkan use case diagram, mulailah membuat activity diagram.
7. Setelah activity diagram selesai dibuat, maka langkah selanjutnya yaitu mendefinisikan objek-objek level atas (package atau domain). Lalu buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
8. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
9. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
10. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan:
11. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
12. Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
13. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
14. Piranti lunak siap dirilis.

Sebuah Video Tutorial tentang Introduction to UML, bisa dilihat disini:
http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

ERD dan Normalisasi

ERD merupakan alat bantu untuk visualisasi pemodelan data. ERD berperan penting dalam melakukan pemodelan data logis. Seperti kita kita bersama, pemodelan data logis sangat penting dalam proses perancangan basis data. ERD juga sangat membantu dalam melakukan normalisasi data.

Pemodelan logic data dikembangkan dalam beberapa tahapan sebagai berikut:

1) Context ERD atau Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis. Banyak hubungan  tersebut mungkin non- spesifik.

Berikut adalah sebuah contoh Context ERD yang menjelaskan mengenai sebuah proses bisnis yang melibatkan entitas-entitas seperti customer, customer order, customer transaction, product dan product_type.

2) Model Data Key-Based

Pada model data key-based, kita telah mulai menyertakan attribute data yang memiliki primary key, foreign key dan entitas asosiatif yang ada. 

Apabila terdapat 2 buah tabel yang mempunyai hubungan many-to-many, maka kedua tabel ini harus dipisahkan dengan cara menambah sebuah tabel diantaranya. Kemudian berikan relevan key di setiap tabelnya dan jangan lupa untuk mengganti notasi kardinalitas pada ketiga tabel tersebut.

Lihat pada contoh gambar diatas. 

Tabel ‘member_order’ and ‘product’ mempunyai hubungan many-to-many. Kedua tabel ini harus dipisahkan dengan menambahkan sebuah tabel dan namakan tabel tersebut ‘member_ordered_product’. Tabel baru ini berisi 2 primary keys yaitu  member_order_id (table member_order) dan product_id (table product). 

Jika ingin memudahkan pengkodean, anda dapat menambahkan sebuah primary key lainnya dan namakan key tersebut ‘member_ordered_product_id (pk)’ di mana key ini mempunyai fungsi yang sama dengan member_order_id (pk) and product_id (pk). Akan tetapi, bila hal ini dilakukan, anda harus mengganti ‘member_ordered_product_id (pk)’ menjadi ‘member_ordered_product_id (fk) dan ‘product_id (pk)’ menjadi ‘product_id (fk)’.

3) Model Data Fully-Attributed

Model data fully-attributed adalah model data logic yang menyertakan semua atribut deskriptif secara menyeluruh.

Lihat pada Gambar dibawah

4) Normalized Data Model

Normalised data model adalah model data logis yang telah melalui proses normalisasi. Pada dasarnya normalisasi adalah suatu teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk mernghilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

Secara singkat tahapan Normalisasi adalah sebagai berikut:

1. Bentuk Normal Tahap Pertama (1st Normal Form)

Pada bentuk ini, semua elemen yang berulang pada suatu entitas      dihapuskan. Dalam 1st Normal Form tidak ada elemen data yang muncul beberapa kali untuk satu entitas tertentu.

2. Bentuk Normal Tahap Kedua (2nd Normal Form)

Dalam bentuk ini pastikan bahwa atribut descriptor bergantung pada seluruh composite key untuk identifikasi.

3. Bentuk Normal Tahap Ketiga (3rd Normal Form)

Dipastikan bahwa nilai atribut tidak bergantung pada nilai atribut lain dalam entitas yang sama.

Pada contoh gambar kita sebelumnya, semua atribut yang ada pada table-tabel di atas sudah normal, maka dari itu tidak perlu dilakukan normalisasi. Jika dalam situasi yang berbeda di mana harus dilakukan normalisasi terhadap tabel-tabel tertentu, pergunakanlah aturan normalisasi dengan benar. Setelah dilakukan normalisasi, maka gabungkan kembali tabel yang sudah dinormalisasi dengan tabel lainnya. 

5) Physical Database Schema

Untuk menggambarkan bagian ini, maka harus mengambil gabungan tabel yang sudah dinormalisasi sebelumnya. Kemudian tambahkan data type dan data length pada setiap atribut yang ada pada tabel-tabel tersebut. Apabila ada batasan-batasan yang harus diketahui, maka hal ini harus dideskripsikan secara singkat pada skema basis.
Lihat contohnya pada Gambar dibawah ini:

Semua Gambar diambil dari buku teks System Analysis and Design for the Global Enterprise - Bentley & Whitten, 7th ed, 2007

Data Flow Diagram

Pemodelan sistem informasi sering dilakukan dengan menggunakan DFD (Data Flow Diagram). Sebelum berkembang pemodelan berorientasi obyek yang menggunakan UML, maka tools DFD sangat sering digunakan. Dalam hubungan dengan metodologi pengembangan sistem informasi maka DFD sering digunakan pada metode Waterfall.
O’brien (1999) menjelaskan bahwa DFD merupakan diagram yang mendemonstrasikan cara data diproses oleh system . Bocij, Chaffey, Greasley, dan Hickie (2003) menjelaskan  diagram konteks merupakan pola penggambaran yang berfungsi untuk memperlihatkan interaksi sistem informasi tersebut dan lingkungan di mana sistem tersebut ditempatkan.
Simbol-simbol yang digunakan dalam DFD menurut DeMarco dan Yourdon, adalah sebagai berikut:

Gambar Simbol-Simbol DFD

Sumber:  Bentley & Whitten, System Analysis and Design for the Global Enterprise 7th ed, 2007

Penjelasan simbol-simbol tersebut dikutip dari McLeod (2001):
1) Arus Data (Data Flow) merupakan kumpulan elemen-elemn data, yang berhubungan secara logis yang bergerak dari satu titik atau process ke titik atau proses lain. Tanda panah menyatakan arah hubungan antar elemen data tersebut
2) Entitas Eksternal (External Entity(, yakni entitas yang berada diluar sistem, tetapi bisa memberikan masukan bagi sistem dan menerima keluaran dari sistem.
3) Proses (Process), adalah sesuatu yang mengubah masukan menjadi keluaran. Tiap proses memiliki satu atau lebih data masukan dan menghasilkan satu atau lebih data keluaran.
4) Penyimpanan Data (Data Storage). Dalam istilah DFD, data store adalah merupakan suatu tempat penyimpanan data.

Berikut adalah aturan mengenai penggambaran Diagram Konteks dan DFD level-n:
Aturan Diagram Konteks:
1. Gunakan satu simbol proses
2. Berikan nama atau label pada simbol proses tersebut untuk menggambarkan seluruh sistem.
3. Tidak menomori simbol proses tersebut.
4. Menyertakan semua extenal entity dari sistem.
5. Menunujukkan semua data flow antara teminator dan sistem.

Aturan Diagram Gambar-n
Diagram gambar-n mendokumentasikan satu proses DFD secara lebih tinggi. Huruf n menggambarkan jumlah proses pada tingkat selanjutnya yang lebih tinggi yang sedang didokumentasikan.
Tahapan Pembuatan DFD
1. Beri label tiap arus data (data flow) dengan nama yang unik.
2. Jaga agar nama arus data tetap dari satu tingkat ke tingkat lain.
3. Tunjukkan penempatan yang tepat bagi catatan-catatan yang dihapuskan dari penyimpanan data.
4. Saat mendokumentasikan program komputer jangan menyertakan proses membaca dan menulis.
5. Hindari proses membaca saja (read-only process).
6. Proses membaca saja diijinkan jika waktu berfungsi sebagai pemicu

Aturan Penggambaran DFD

Berikut saya berikan contoh langkah-langkah untuk menggambar DFD:
1) Menggambar Functional decomposition diagram (FDD)
2) Menggambar Context DFD (Level 0)
3) Menggambar DFD Level 1
4) Menggambar DFD Level 2 … Level n (Event diagrams)
Contoh kasus adalah sebuh Proses Sales Processing!

Gambar FDD

Gambar Context Diagram

Gambar DFD Level 1

Gambar DFD Level 2

Sebuah contoh lainnya tentag Pemodelan menggunakan DFD dapat dilihat disini ....

Eliminasi Gauss

Praktikum Metode Numerik
Modul 5 Metode Eliminasu Gauss
BAB I
TUJUAN DAN DASAR TEORI

I.1. Tujuan
1) Menguasai metode eliminasi gauss yang digunakan dalam komputasi numerik
2) Memahami algoritma pemrograman untuk merancang program metode eliminasi gauss yang ada dalam komputasi numerik
3) Menerapkan algoritma untuk perancangan dan pembuatan program metode eliminasi gauss.

II.2. Dasar Teori
Berikut ini dipaparkan metode 2 langkah dalam menyelesaikan persamaan dengan Gaussian Eliminasi.

Langkah ke-1:
Melakukan proses triangulasi = mengubah matriks A menjadi matriks segitiga (hal ini akan mengubah matriks B)

Langkah ke-2:
Melakukan substitusi mundur, yaitu: menghitung x mengikuti urutan terbalik, dari yang terakhir (Xn ) sampai yang pertama (X1 )

Modul selengkapnya dapat diunduh disini

Metodologi RAD - Rapid Application Development

Metodologi RAD merupakan salah satu metodologi pengembangan perangkat lunak yang "cepat". RAD merupakan hasil adaptasi dari Waterfall yang dirasakan cukup lama. Saya pernah membimbing seorang mahasiswa KP/TA dengan menggunakan metodologi RAD dalam mengembangkan aplikasi berbasis web. 

Berikut adalah catatan saya mengenali langkah-langkah metodologi RAD. Dalam metode RAD terdapat langkah-langkah yang dibagi dalam empat fase. Langkah-langkah metode RAD adalah sebagai berikut:
 

3.1 Fase Analisis Persyaratan
Fase ini memiliki tujuan untuk mengidentifikasi layanan, batasan, dan obyektifitas dari sistem dari pengumpulan data yang dilakukan terhadap stakeholders. Selain itu analisis persyaratan juga bertujuan untuk mendefinisikan persyaratan user dan sistem. Hasil akhir dari analisis persyaratan yaitu spesifikasi awal dari persyaratan user dan sistem. Adapun Fase 1 ini terdiri dari 5 langkah  yaitu sebagai berikut:
a.    Langkah 1.1:  Komunikasi dan Perencanaan Proyek
Tujuan dari langkah komunikasi dan perencanaan proyek adalah untuk mengidentifikasi kegiatan, patokan, dan apa yang harus dihasilkan oleh proyek. Langkah 1.1 ini menghasilkan perencanaan proyek, manajemen perubahan persyaratan dan manajemen resiko.
b.    Langkah 1.2:  Studi kelayakan
Tujuan dari studi kelayakan adalah untuk menentukan apakah proyek dapat dilanjutkan. Jika proyek dapat diteruskan, studi kelayakan akan menghasilkan rencana proyek dan estimasi biaya untuk tahap pengembangan selanjutnya. 

Ada 4 macam studi kelayakan yang dapat dilakukan yaitu:

i.  Teknis: Kelayakan teknis digunakan untuk menentukan penggunaan solusi teknis tertentu dalam sistem/proyek, dan ketersediaan sumber daya dan keahlian teknis.

ii.  Operasional: Kelayakan operasional adalah ukuran seberapa baik solusi akan berhasil dalam organisasi. Studi kelayakan ini juga mengukur persepsi orang akan sistem/proyek.

iii.  Ekonomi: Kelayakan ekonomi digunakan untuk mengukur biaya yang mempengaruhi proyek/solusi. 

iv.  Penjadwalan: Kelayakan penjadwalan digunakan untuk mengukur timeline proyek. 

c.   Langkah 1.3:  Spesifikasi pengguna

Tujuan dari spesifikasi pengguna yaitu untuk mengidentifikasi dan menetapkan kebutuhan user mengenai apa yang akan dicapai oleh proyek ini. Hasil dari daftar pengguna beserta tugas dan tanggung jawabnya, problem statement matrix, dan daftar prioritas kebutuhan pengguna.
d.    Langkah 1.4:  Spesifikasi sistem

Tujuan dari spesifikasi sistem adalah menjelaskan kebutuhan dan keinginan akan adanya sistem informasi. Dapat memberikan deskripsi mengenai fungsi-fungsi, fitur-fitur (atribut) dan batasan-batasan yang dibutuhkan sistem. Langkah ini menghasilkan pernyataan yang jelas mengenai tujuan dibangunnya sistem, fitur-fitur aplikasi dan batasan-batasannya.
Semua hasil dari langkah-langkah yang terdapat dalam fase 1 ada pada dokumen fase 1.
 

3.2 Fase Analisis Modeling
Tujuan dari fase analisis modeling adalah menganalisis semua kegiatan dalam arsitektur sistem secara keseluruhan dengan melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Selain itu, analisis modeling juga bertujuan untuk meningkatkan pemahaman terhadap permasalahan tanpa mempertimbangkan solusi teknis. Hasil akhir dari analisis modeling yaitu diagram model logis dari sistem yang sedang berjalan, diantaranya use case diagrams, class diagram, dan sequence diagrams. Fase 2 ini terdiri dari:
a.    Langkah 2.1:  Mengidentifikasi pelaku bisnis
Tujuan dari langkah ini yaiut untuk mengidentifikasi user yang terlibat dalam bisnis proses beserta dengan peranan/tanggung jawab mereka dalam penggunaan sistem. Hasilnya adalah daftar aktor beserta tugas dan tanggung jawabnya.
b.    Langkah  2.2:  Menganalisis proses dan kinerja sistem

Tujuannya yaitu untuk memperoleh deskripsi secara jelas mengenai dukungan fungsional dan non-fungsional yang menjadi kebutuhan terhadap sistem yang dikembangkan dengan menggunakan model diagram use case. Hasil dari langkah ini yaitu use case diagram.
c.    Langkah 2.3: Mengidentifikasi struktur obyek dan relasinya

Tujuan dari langkah ini yaitu untuk mengidentifikasi dan pemodelan kelas objek dalam sistem yang akan dikembangkan, yang menggambarkan struktur obyek dalam sistem.
i.    Menemukan objek yang potensial

Tujuannya yaitu untuk menemukan kata benda yang berhubungan dengan entitas bisnis. Hasilnya yaitu daftar objek yang berpotensi.
ii.    Mendokumentasikan bisnis obyek dan relasinya
Tujuannya untuk mengatur obyek-obyek yang telah diidentifikasi dan mendokumentasikan hubungan konseptual utama antara obyek-obyek tersebut. Hasilnya adalah class diagram (yang dikenal juga sebagai object association diagrams).
iii.    Analisis perubahan keadaan obyek
Tujuannya adalah untuk mengidentifikasi dan memodelkan obyek yang mengalami perubahan keadaan. Hasil dari analisis perubahan keadaan obyek yaitu activity diagrams.
 

3.3 Fase Desain Modeling
Tujuan dari fase desain modeling yaitu melakukan perancangan sistem berdasarkan analisis yang telah dilakukan sebelumnya. Tahap analisis dan desain mengalami perulangan hingga diperoleh rancangan sistem yang benar-benar memenuhi kebutuhan. Selain itu, fase 3 ini juga bertujuan untuk memberikan spesifikasi yang jelas dan lengkap kepada programmer dan teknisi. Hasil akhir dari fase ini yaitu basis data, antarmuka, dan spesifikasi desain. Fase 3 ini terdiri dari:
a.    Langkah 3.1:  Memodelkan kembali diagram use case untuk  merefleksikan  lingkungan  implementasi
Tujuanya adalah untuk memperlihatkan perubahan dari analisis use case menjadi desain use case dan memperbaharui model diagram use case dengan menambahkan lebih banyak fakta dari proses pengembangan dan dokumentasi untuk memperlihatkan use case yang baru. Hasil dari langkah 3.1 adalah design use cases (physical.)
b.    Langkah 3.2:  Memodelkan interaksi obyek dan behaviours
Tujuannya adalah untk mengidentifikasi dan mengelompokkan perancangan obyek dan atribut-atribut yang dibutuhkan secara fungsional yang telah dispesifikkan sebelumnya lewat setiap use case dan mengidentifikasi object interactions. Hasilnya yaitu daftar interface, control, dan entity untuk setiap obyek., use case diagram, activity diagram, sequence diagram.
c.    Langkah 3.3:  Desain antarmuka
Tujuannya adalah untuk menyediakan detail elemen multimedia yang akan digunakan, message yang akan disampaikan, presentasi isi, map navigasi, contoh halaman, dan storyboard. Hasil dari tahap 3.3 yaitu storyboard.
d.    Langkah 3.4:  Membuat algoritma
Tujuannya yaitu untuk merepresentasikan prosedur logic dari fungsi yang dibuat dalam aplikasi. Hasilnya adalah flowchart.
 

3.4 Fase 4: Konstruksi
Tujuan dari fase konstruksi adalah untuk menunjukkan platform, hardware dan software yang digunakan serta batasan dalam implementasi, serta menguji performansi prototipe perangkat lunak yang telah dibangun agar dapat diketahui apakah prototipe tersebut telah sesuai dengan spesifikasi analisis dan perancangan yang telah diidentifikasi sebelumnya. Hasil akhir dari fase konstruksi adalah platform, hardware dan software yang digunakan, serta daftar batasan implementasi, dan rencana pengujian. Fase 4 ini terdiri dari:
a.    Langkah 4.1: Lingkungan implementasi
Tujuannya yaitu menfasilitasi pengembangan sistem dengan menggunakan perangkat keras dan perangkat lunak yang sudah disediakan. Hasilnya adalah daftar perangkat keras dan perangkat lunak.
b.    Langkah 4.2: Implementasi basis data
Tujuannya yaitu membangun basis data berdasarkan pemodelan kelas objek. Hasilnya adalah basis data sistem.
c.    Langkah 4.3: Melakukan pemrograman
Tujuannya yaitu membuat pengkodean sistem berdasarkan model algoritma dan diagram objek yang telah dirancang.Hasilnya adalah kode program.
d.    Langkah 4.4: Implementasi antarmuka
Tujuannya adalah untuk membangun antarmuka pengguna. Hasilnya adalah kode program lengkap dengan antarmuka pengguna.
e.    Langkah 4.5: Pengujian
i. Identifikasi tujuan pengujian sistem.
Tujuannya untuk emperoleh tujuan pengujian sistem agar dapat digunakan sesuai dengan kebutuhan. Hasilnya daftar tujuan pengujian sistem.
ii. Buat kriteria pengujian sistem
Tujuannya untuk mengidentifikasi kriteria pengujian sistem sehingga menjadi tolak ukur dalam analisis hasil pengujian. Hasilnya daftar kriteria pengujian sistem pakar.
iii. Buat kasus untuk pengujian
Tujuannya untuk menentukan skenario yang akan dilaksanakan dalam pengujian sehinga pengujian dapat dilakukan secara terarah. Hasilnya daftar kasus untuk pengujian.
iv. Lakukan Pengujian Sistem
Tujuannya melaksanakan serangkaian kegiatan pengujian berdasarkan tujuan dan kasus uji. Hasilnya test plan.   

Metodologi AUP

Metodologi AUP atau Agile - Unified Process merupakan suatu metodologi pengembangan perangkat lunak yang mulai marak digunakan. Menurut hemat saya, metodologi ini paling cocok digunakan oleh mahasiswa dalam menyelesaikan tugas proyek mata kuliah ataupun mengerjakan laporan Kerja Praktek (dan Tugas Akhir)

Gambar 1 menunjukkan menunjukkan Tahapan Proses dan Aktivitas Metodologi AUP

Gambar 2 menunjukkan urutan akvitas pada masing-masing fase AUP

Tahapan pemecahan masalah dengan metodologi AUP, mengikuti langkah-langkah yang dikeluarkan oleh Pusilkom Universitas Indonesia. Panduan Agile UP ini mengacu pada metodologi yang dibuat oleh Ambysoft Inc (lihat Gambar 1 dan Gambar 2). Garis besar tahapan analisa dan perancangan yang dilakukan adalah sebagai berikut:
1)    Inception, 

dengan aktivitas mendefinisikan project scope, mengestimasi biaya dan penjadwalan, mendefinisikan resiko, membuat kelayakan proyek dan mempersiapkan lingkungan pengerjaan proyek (tim, tempat kerja, instalasi, dan sebagainya). Proses iterasi dilakukan satu kali. Artifak yang dihasilkan diantaranya adalah dokumen Vision, dokumen Supplementary Specification, dokumen Glossary, Gantt Chart dan Iteration Plan.

2) Elaboration, 

dengan aktivitas mengidentifikasi dan validasi arsitektur aplikasi. Proses iterasi dapat dilakukan satu sampai dua kali. Artifak yang dihasilkan adalah UML Use Case, Model Arsitektur (update dan snapshot), Architecture Prototype Code, Scenario Test Plan, dokumen Business Rule, dokumen Supplementary dan Glossary yang telah diupdate.
 

3) Construction, 

dengan aktivitas memodelkan, membangun dan menguji sistem aplikasi (unit testing) serta membuat dokumentasi pendukung. Proses iterasi dapat dilakukan dua hingga delapan kali. Artifak yang dihasilkan adalah Use Case (yang telah diupdate), dokumen Supplementary dan Glossary (yang telah diupdate), Domain Model (snapshot), UML Activity Diagram (snapshot), UML Class Diagram (snapshot), CRC Card, UML Sequence Diagram (snapshot), Source Code, Code Documentation, Regression Test Suite, Acceptance Test dan Bugs Report.

4) Transition, 

dengan aktivitas menguji sistem (integration sistem dan user testing), mereview kembali sistem aplikasi dan menginstalasi sistem aplikasi. Proses iterasi dapat dilakukan satu hingga dua kali. Artifak yang dihasilkan adalah Dokumen System Requirement Specification, Dokumen System Technical Specification, Panduan Instalasi dan Panduan Pengguna, Dokumen Pelatihan, Regression Test Suite, User Acceptance Test dan Bugs Report (yang sudah final). 

Panduan Agile UP dari Pusilkom UI juga memberikan best practice dalam melakukan setiap aktivitas di setiap fase. Panduan ini juga membedakan artifak dokumen yang dihasilkan, sebagai artifak utama, artifak pendukung dan artifak input dan artifak output. Panduan ini juga memberikan LCO (Lifecycle Obejctive) berupa dokumen dan presentasi dari setiap fase, sebagai target yang harus dicapai sebelum melanjutkan ke fase yang selanjutnya. Untuk kepentingan penulisan paper ini, maka penulis akan membatasi artifak yang akan ditampilkan.

Web Engineering Methodology

Salah satu metodologi pengembangan aplikasi Web adalah dengan menggunakan metode Web Engineering (disingkat WebE). Saya pernah menggunakan metode ini untuk mengembangkan aplikasi berbasis web Official Website Kantor Sinode GMIM.

Berikut cuplikan laporan hasil pengembangan aplikasi ....
Untuk mengembangkan Aplikasi Web Sinode GMIM, akan menggunakan pendekatan RAD dan WebE. Kombinasi kedua pendekatan ini, menghasilkan langkah-langkah pemecahan masalah yang lebih komprehensif.

Langkah-langkah pemecahan masalah tersebut adalah:
1. Fase Analisis Persyaratan
Fase ini memiliki tujuan untuk mengidentifikasi layanan, batasan, dan obyektifitas dari sistem dari pengumpulan data yang dilakukan terhadap stakeholders. Selain itu analisis persyaratan juga bertujuan untuk mendefinisikan persyaratan user dan sistem. Hasil akhir dari analisis persyaratan yaitu spesifikasi awal dari persyaratan user dan sistem. Adapun Fase 1 ini terdiri dari 5 akitivitas  yaitu sebagai berikut:
a. Melakukan Komunikasi dan Perencanaan Proyek
b. Melakukan Studi kelayakan (Teknis, Operasional dan Ekonomi)
c. Melakukan Penjadwalan
d. Menentukan Spesifikasi Pengguna
e. Menentukan Spesifikasi Sistem

2. Fase Analisis Modeling
Tujuan dari fase analisis modeling adalah menganalisis semua kegiatan dalam arsitektur sistem secara keseluruhan dengan melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Selain itu, analisis modeling juga bertujuan untuk meningkatkan pemahaman terhadap permasalahan tanpa mempertimbangkan solusi teknis. Hasil akhir dari analisis modeling yaitu diagram model logis dari sistem yang sedang berjalan, diantaranya use case diagrams, class diagram, dan sequence diagrams. Aktivitas di fase Analisis Modelling adalah:
a. Mengidentifikasi pelaku bisnis
b. Menganalisis proses dan kinerja sistem
c. Mengidentifikasi struktur obyek dan relasinya

3. Fase Desain Modeling
Tujuan dari fase desain modeling yaitu melakukan perancangan sistem berdasarkan analisis yang telah dilakukan sebelumnya. Tahap analisis dan desain mengalami perulangan hingga diperoleh rancangan sistem yang benar-benar memenuhi kebutuhan. Selain itu, fase 3 ini juga bertujuan untuk memberikan spesifikasi yang jelas dan lengkap kepada programmer dan teknisi. Hasil akhir dari fase ini yaitu basis data, antarmuka, dan spesifikasi desain. Aktivitas Desain Modelling ini adalah:
a. Memodelkan kembali diagram use case untuk  merefleksikan  lingkungan  implementasi
b. Memodelkan interaksi obyek dan behaviours
c. Desain antarmuka
d. Membuat algoritma

4. Fase Konstruksi
Tujuan dari fase konstruksi adalah untuk menunjukkan platform, hardware dan software yang digunakan serta batasan dalam implementasi, serta menguji performansi prototipe perangkat lunak yang telah dibangun agar dapat diketahui apakah prototipe tersebut telah sesuai dengan spesifikasi analisis dan perancangan yang telah diidentifikasi sebelumnya. Hasil akhir dari fase konstruksi adalah platform, hardware dan software yang digunakan, serta daftar batasan implementasi, dan rencana pengujian. Aktivitas pada fase Konstruksi adalah:
a. Mendeskripsikan Lingkungan implementasi
b. Implementasi basis data
c. Melakukan pemrograman
d. Implementasi antarmuka
e. Pengujian; yakni identifikasi tujuan pengujian system, membuat kriteria pengujian system, membuat kasus untuk pengujian, melakukan Pengujian Sistem

pengantar UML ...

UML adalah singkatan dari Unified Modeling Language, yaitu suatu notasi pemodelan aplikasi perangkat lunak. Schach[1] menegaskan bahwa UML merupakan bahasa bukan metode. Sebagai bahasa, UML digunakan untuk mendeskripsikan perangkat lunak yang dikembangkan dengan berbagai pradigma pengembangan perangkat lunak dan metodologi. Pendapat Schach[1] didukung oleh Sommerville[2] dan Pressman[3].  

Dennis, Wixom dan Tegarden[4] mendukung pendapat bahwa UML merupakan kumpulan standar pemodelan dengan menggunakan diagram, dimana UML bertujuan untuk menyediakan kosa-kata dari paradigma pengembangan sistem berorientasi obyek guna memodelkan semua tahapan dari daur hidup pengembangan perangkat lunak. Bentley dan Whitten[5], mendukung pemahaman bahwa UML merupakan kumpulan alat pemodelan yang disepakati bersama untuk menjelaskan sistem perangkat lunak. Hal serupa dikemukakan oleh Kendall dan Kendall[6].

Fowler[8] memberikan definisi yang sederhana bahwa UML merupakan kumpulan notasi grafis, yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi obyek. UML merupakan standar yang relatif terbuka yang diatur oleh Object Management Group (OMG), sebuah konsorsium terbuka. OMG berfungsi untuk membuat standar-standar yang mendukung interoperabilitas sistem yang berorientasi objek. Versi terakhir dari UML adalah UML ver 2.0[9].

Menurut Kruchten[10], UML adalah bahasa grafis untuk visualizing, specifying, constructing and documenting setiap artifak dari sistem perangkat lunak.

UML mendukung The 4+1 View Model of Architecture, yakni 

1) The Logical View, 

2) The Implementation View, 

3) The Process View dan 

4) The Deployment View ditambah dengan 

5) The Use Case View.

Lihat Gambar dibawah ini tentang pemetaan UML pada Architecture Model Perangkat Lunak:

Model merupakan representasi lengkap dari sistem perangkat lunak, sedangkan arsitektur merupakan fokus pandangan pada bagian-bagian tertentu dari sistem perangkat lunak. Atau dapat dikatakan arsitektur sistem merupakan cetak-biru aplikasi. Keterhubungan model dan arsitektur sistem perangkat lunak, digambarkan oleh UML.

Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:
Rational Rose (www.rational.com)
Together (www.togethersoft.com)
Object Domain (www.objectdomain.com)
Jvision (www.object-insight.com)
Objecteering (www.objecteering.com)
MagicDraw (www.nomagic.com/magicdrawuml)
Visual Object Modeller (www.visualobject.com)
Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa anda pelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html .
Disamping itu, daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di
http://www.jeckle.de/umltools.htm.


Referensi Site UML
Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer
penting adalah:
http://www.cetus-links.org/oo_uml.html
http://www.omg.org
http://www.omg.org/technology/uml/
http://www.rational.com/uml
http://www.uml.org/

Tulisan lainnya tentang UML dapat ditemukan disini

Sumber Acuan

[1] Schach, Object Oriented Software Engineering, 8th Ed, McGrawHill, 2008. 

[2] Sommerville, Software Engineering, 8th ed, Pearson Education Limited, 2007

[3] Pressman, Software Engineering, A Practitioner’s Approach, 6th ed, McGrawHill, Singapura, 2005.

[4] Dennis, Wixom and Tegarden, System Analysis and Design with UML, An Object-Oriented Approach, 3dh ed, John Wiley & Sons, International Student Edition, 2010.

[5] Bentley and Whitten, System Analysis and Design for the Global Enterprise, 7th ed, McGrawHill International Edition, 2007.

[6] Kendall and Kendall, System Analysis and Design, 7th ed, Pearson Prentice Hall, 2007.

[7] CMMI Product Team, CMMI® for Development, Version 1.3, Improving processes for developing better products and services, November 2010, TECHNICAL REPORT CMU/SEI-2010-TR-033 , ESC-TR-2010-033, Software Engineering Process Management Program, Unlimited distribution subject to the copyright. http://www.sei.cmu.edu.

[8] Martin Fowler, UML Distilled, A Brief Guide to the Standard Object Modelling Language, 3th ed, Pearson Education, 2004.

[9] www.uml.org., Unified Modelling Language: Superstructure Version 2.0, ptc/03-08-02.

[10] Philippe Kruchten, The Rational Unified Process An Introduction, 3rd ed, Pearson Education, 2004.

draft Analisa dan Perancangan Sistem Informasi e-Direktori Pariwisata

RANCANGAN ANALISA SISTEM

e-Direktori Pariwisata Sulawesi Utara

Perancangan analisa sistem merupakan suatu kegiatan yang berisi proses analisis dan perancangan aplikasi. Tujuan aktivitas ini adalah untuk mengimplementasikan semua objek dan proses dalam tahap analisis menjadi karakteristik yang dikenali computer:

1. Tujuan Sistem

Tujuan utama pembuatan sistem ini adalah sebagai alat bantu bagi wisatawan, dan khususnya pengelola hotel atau kuliner, baik perorangan maupun organisasi.

2. Analisa Kebutuhan Sistem

e-Direktori Pariwisata Sulawesi Utara (SIP) diharapkan dapat memenuhi beberapa kebutuhan yang terkait dengan pemanfaatan potensi pariwisata provinsi Sulawesi Utara. Kemampuan yang dapat diberikan oleh SIP ini berupa:

1. Sebaran lokasi hotel dan kuliner.

2. Informasi atribut hotel dan kuliner

3. Informasi jalur angkot yang melewati lokasi hotel dan kuliner

4. Informasi terkait lainnya

2.1 Analisa Perangkat Lunak

Pada perancangan sistem informasi Posisi ini, perangkat lunak yang digunakan adalah Macromedia DreamWeaver, PHP dan mySQL. Pemilihan perangkat lunak dan bahasa pemrograman ini didasarkan pada kemampuan perangkat lunak tersebut yang dapat mengolah data berupa peta dan menampilkan informasi dan tampilan yang lebih bagus dibanding dengan perangkat lunak lainnya.

2.2 Analisa Perangkat Keras

Agar dapat berjalan dengan baik maka dibutuhkan harddisk yang berkapasitas minimal 5 GB, processor minimal 800MHZ (Intel maupun AMD), memory minimal 64 MB dan VGA minimal 32 MB. Implementasi SIP ini sangat membutuhkan perangkat keras yang cukup tinggi, dengan kata lain dibutuhkan spesifikasi computer yang cukup tinggi. Hal ini dikarenakan data yang diakses dan yang disimpan tidak hanya dalam bentuk data tabular melainkan adanya data Posisi yang memiliki kapasitas data yang besar untuk menampilkan informasi dan tampilan secara interaktif. Jika spesifikasi perangkat keras yang digunakan tidak memenuhi persyaratan minimal, proses masih dapat berjalan namun dengan kinerja yang cukup lambat.

2.3 Spesifikasi Masukan Sistem

Masukan sistem terdiri dari data – data:

1. Data spasial hotel.

2. Data spasial kuliner.

3. Data angkutan

4. Informasi hotel, kuliner dan angkutan

5. Pencarian.

2.4 Spesifikasi Keluaran Sistem

Hasil sistem berupa:

1. Visualisasi lokasi hotel

2. Visualisasi lokasi kuliner

3. Visualisasi angkutan.

4. Analisa Bersyarat (query).

3. Analisa Pengolahan Data

Proses analisis pengolahan data terdiri dari: visualisasi, pengolahan data (input, edit, update dan delete), cari informasi dan tampilkan informasi.

3.1 Analisa Data Spasial

Analisis menggunakan data spasial yang tediri dari peta jalan, peta hotel, peta kuliner. Skala peta yang digunakan adalah 1:20.000, dengan kedalaman inforamsi pada indentifikasi jalan, luas area kecamatan dan jumlah hotel dan kuliner. Data spasial digunakan sebagai alat bantu pengambilan keputusan melalui hasil visualisasi.

3.2 Analisa Data Non Spasial

Data non spasial disebut juga sebagai atribut dari data spasial. Fungsinya adalah membangun database untuk analisa atau pengolahan data, sehingga dapat memberikan informasi yang dibutuhkan. Data non spasial yang dibutuhkan untuk analisa adalah masing – masing atribut pada data spasial, misalnya atribut jalan, atribut hotel dan atribut kuliner.

3.3 Proses Manage Data

Merupakan proses manage data – data teknis dari gambaran tentang perhotelan dan kuliner provinsi Sulawesi Utara yanga da. Manage data dilakukan untuk menjaga keakuratan data, terutama untuk data yng terus berubah. Proses manage data hanya bisa dilakukan oleh administrator (user tidak diberikan fasilitas ini) atau dengan membuat table dan field baru apabila ada jenis informasi yang diinginkan.

3.4 Penentuan Sebaran Hotel dan Kuliner

Penentuan sebaran hotel dan kuliner dengan cara memilih hotel atau kuliner tertentu yang berbeda dalam suatu theme untuk ditampilkan informasinya secara sendiri.

3.5 Pencarian Hotel dan Kuliner

Proses pencarian hotel dan kuliner dengan cara memilih layer tertentu dan mengaktifkan theme lain yang kemudian dikoneksikan dengan area berdasarkan atribut yang dipilih.

3.6 Analisa Bersyarat

Analisa bersyarat merupakan proses pencarian informasi berdasarkan field – field atribut pada suatu theme. Proses ini dilakukan dengan memilih informasi yang ditampilkan berdasarkan field yang diinginkan.

3.7 Visualisasi

Proses visualisasi ini merupakan ciri khas yang membedakan sistem informasi Posisi dengan sistem informasi lainnya. Dalam visualisasi ini, tampilan yang disajikan dapat dipilih layer mana saja yang diinginkan untuk divisualisasikan, yaitu dengan fasilitas layer control.

3.8 Cari Informasi

Proses ini dilakukan melalui fasilitas query yang terdiri dari find. Didalamnya diinputkan informasi apa yang akan dicari. Tabel beserta fieldnya. Khususnya untuk find, hasilnya dapat langsung ditunjukan di map-nya dalam bentuk symbol. 

3.9 Tampilkan Informasi

Proses menampilkan informasi ini dilakukan dalam bentuk tampilan legend, info tool dan grafik.

4. Kekuatan dan Kelemahan Sistem

4.1 Kekuatan Sistem

Kekuatan sistem yang dihasilkan dapat dilihat dari berbagai aspek, yaitu implementasi, user interface, tampilan, aplikasi, program dan buku petunjuk pengguna.

1) Implementasi

a. Perangkat lunak yang digunakan dapat bertukar data dengan basis data yang dimiliki sehingga memudahkan dalam implementasi sistem.

b. Memiliki banyak fasilitas yang dapat digunakan.

c. Memudahkan dalam analisa untuk perancangan.

2) User Interface

a. Tersedia informasi langsung dalam tiap proses, sehingga mudah dalam memahami proses

b. Tersedianya button, tools dan menu yang lengkap dan praktis untuk pengolahan data membuat aplikasi lebih mudah.

3) Tampilan

a. Penampilan symbol dan warna pada setiap layer peta membuat tampilan lebih menarik dan interaktif.

b. Tool dan button yang disediakan dengan tampilan yang unik, sederhana sehingga mudah dipahami.

c. Dilengkapi dengan design yang menarik.

d. Terlihat info tool, legenda yang terpisah membuat tampilan penyajian data lebih mudah untuk dilihat dan tidak membingungkan.

4.2 Kelemahan Sistem

Menu – menu yang ada sangatlah terbatas karena memang dirancang agar menunya praktis dan mudah dipahami oleh user/pengguna.

5. Analisa Orientasi Pemakai

Pemakai sistem dibagi ke dalam dua kelompok, yaitu:

1. Pemakai umum (atau user)

Pemakai umum dapat mengakses fungsi – fungsi analisa Posisi (aplikasi).

2. Administrator (admin) aplikasi

Administrator SIP berhak mengakses semua fungsi di dalam sistem, termasuk pengelolaan data dan penggunaan password.

Untuk diagram Perancangan bisa diunduh disini